[アップデート] Amazon CodeCatalyst で新しいロールが追加されたので、スペース・プロジェクトそれぞれの違いを復習しながら確認してみた

[アップデート] Amazon CodeCatalyst で新しいロールが追加されたので、スペース・プロジェクトそれぞれの違いを復習しながら確認してみた

Clock Icon2023.11.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

Amazon CodeCatalyst を使ってチーム開発を行うことが出来ますが、通常は複数のユーザーを招待して利用します。
その際、ユーザーにロールを割り当てることでどこまでの権限を許可するか制御することが可能です。
このロールは現時点では権限のカスタマイズは出来ず、プリセットされた数パターンのロールの中から選択します。

本日のアップデートで新しいロールがいくつか追加されました。

CodeCatalyst のロールはスペースに対するロールとプロジェクトに対するロールがあり、概念がちょっとややこしいです。
本日は具体的な変更点を確認しつつ、スペースとプロジェクトそれぞれのロールの挙動の違いについて紹介してみようと思います。

スペースとプロジェクトそれぞれメンバー管理機能がある

Amazon CodeCatalyst のスペースやプロジェクトなどの概念は以前整理したことがありまして、よろしければこちらの記事もご覧ください。

スペースがチームのワークスペースでその中に複数のプロジェクトを作成します。
スペースとプロジェクトにはそれぞれオーナーが存在し、別のユーザーを招待する形となります。
なお、Amazon CodeCatlyst は通常の AWS サービスとは異なっており、AWS Builder ID のユーザーを管理します。
AWS アカウントはあくまでもスペースの請求先やデプロイ先として紐付けるようなイメージになっています。

スペース

スペースの設定画面からスペースメンバーを管理することが出来ます。
ユーザーの招待時、あるいは登録済みのユーザーのロールを指定・変更することが出来ます。

スペースで明示的に設定できるロールは、以前までは「Space administrator」のみでした。
今回のアップデートで「Limited access」と「Power user」が追加されています。

後ほど軽く確認しますが、Limited access は参照用、Power user は請求やユーザー以外の操作が可能な管理者というイメージです。
詳細な権限内容は公式ドキュメントをご確認ください。

プロジェクト

スペースに追加されただけだと、実はまだプロジェクトにアクセス出来ません。
スペースの管理者あるいはプロジェクトオーナーからプロジェクトメンバーとして招待してもらう必要があります。

このプロジェクトメンバーについても先程のスペースロールとは別で、ロールの概念があります。
従来は「Contributor」「Project administrator」の 2 つが存在していましたが、今回のアップデートで新たに「Reviewer」と「Read-only」が追加されました。

Reviewer はプルリクエストのレビューやコメントが可能ですが、クローズやマージは出来ません。
イシューの起票や更新なども可能です。

Read-only はプロジェクト内のすべての更新アクションは許可されておらず、読み取りのみが可能です。

こちらも詳細な権限内容は次の公式ドキュメントをご確認ください。かなり細かいですが。

権限を割り当てて許可されている操作、されていない操作を確認してみる

許可された操作はまぁ公式ドキュメントのとおりなのですが実際に使ってみましょう。
特に、許可されていない操作がどのような拒否のされた方をするのか気になるところです。

スペースロールの確認

まず、Power user ロールでスペース内の各機能を確認してみましょう。

プロジェクトの新規作成は出来ますね。

メンバー管理機能については招待や削除、ロール変更などの操作は出来ませんでしたが、参加ユーザーの情報を確認することは出来ました。

また、拡張機能のインストールも可能でした。
拡張機能...実装当初から増えてないですね。むむ。

意外だったのですが、使用量などについても Power User で確認することが出来ました。
ただし、料金プランや AWS アカウントの紐づけ管理などは操作が出来ませんでした。このあたりはスペース管理者力が必要か。

一方で、Limited Access ロールのユーザーの場合はプロジェクト作成が出来ませんでした。

また、拡張のインストールも出来ませんね。権限不足だと言われます。

メンバー管理については Power User と同様で、読み取り専用という形でした。
スペースに参加しているユーザーが閲覧出来てしまうので、スペースに関係のないプロジェクトを混在させるのは避けたほうが良さそうですね。
複数スペースを作成することが出来るので同一の利害関係者ごとにスペースを作成するのが良いのかなという感じがします。

プロジェクトロールの確認

続いてスペースに招待したユーザーを特定のプロジェクトへも追加します。

どちらのロールの場合もプロジェクトメンバーを参照することは可能でした。
このあたりはスペースと同様ですね。

Reviewer で新しいイシューを作成することが出来ました。

リポジトリの作成などは出来ませんね。ボタンが非活性になっています。
ワークフローについてはボタンは非活性ではなかったのですが、実行や作成の操作をしたところ権限不足によるエラーメッセージが表示されました。

公式ドキュメントのとおりの権限制限がされているようですが、必ずしもわかりやすくボタンやメニューが非活性になっているわけではないようですね。

Project member

CodeCatalyst ではスペースへ招待していないユーザーをプロジェクトへ招待することが出来ます。
今回気がついたのですが、この場合はスペース上に「Project member」というロールでユーザーが表示されます。

このロールは実体としては Limited Access ロールと同様の権限になるようです。
いくつか私のほうで確認したところスペース上の読み取り専用ユーザーの挙動をしているのがわかりました。

公式ドキュメント上はこの点について次のような補足がされています。

Users who accept an invitation to a project have the Limited access role automatically assigned to them in the space that contains the project.

引用元:Working with roles in Amazon CodeCatalyst - Amazon CodeCatalyst

さいごに

本日は Amazon CodeCatalyst で新しいロールが追加されたので、スペース・プロジェクトそれぞれの違いを復習しながら確認してみました。

ユースケースとしてロール名のとおりでプルリクエストのレビュアー用だったり、プロジェクトのステークホルダーに読み取り専用権限を付与するような使い方になりそうです。
文中に記載しましたが、制限されたロールのユーザーでもある程度の情報を参照することが可能なので、情報の開示範囲を狭めるような使い方にロールは使えなさそうですね。スペースやプロジェクトを複数に分離し、適切な場所へ招待するようにしたほうが良さそうです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.